home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
NetNews Offline 2
/
NetNews Offline Volume 2.iso
/
news
/
comp
/
std
/
c
/
380
< prev
next >
Wrap
Text File
|
1996-08-06
|
3KB
|
53 lines
Newsgroups: comp.std.c
Path: nntp.coast.net!torn!sq!msb
From: msb@sq.com (Mark Brader)
Subject: Re: fast block zeroing, how defined?
Message-ID: <1996Feb16.082224.16087@sq.com>
Organization: SoftQuad Inc., Toronto, Canada
References: <4fqaj4$2qu@fu-berlin.de> <TANMOY.96Feb13124302@qcd.lanl.gov>
Date: Fri, 16 Feb 1996 08:22:24 GMT
To the question:
> > Are the representation of zeros in intergral types defined
> > as multiple "char" zeros? (This is true in all the implementations
> > I know of, but it should be also defined in the standard that way)
Tanmoy Bhattacharya (tanmoy@qcd.lanl.gov) answers:
> All the significant bits of zero of an integral type, except for the
> highest, must be zero. Unfortunately, it has been decided that not all
> bits are significant. I conclude that some of them can be used for
> parity checks, and I conclude the top bit being zero (with others
> being zero) can result in an invalid value. I am not familiar enough
> with the standard to guarantee my conclusions have any merit: but I
> would like to know why they are wrong if they are.
"It has been decided" refers to the official response to Defect
Report 67, contained in Record of Response 2 and Technical Corri-
gendum 2. As far as I know, RR2/TC2 has still not been published,
and I have no idea what changes may have been made in response to
comments made through national bodies during balloting.
In the draft version that was balloted on, it does state that some
integral types can have unused bits; the term defined to refer to these
bits is, unfortunately, "holes". The draft states that they "do not
participate in forming the value of an object"; that is, they must
simply be ignored, rather than being possibly used for parity.
An exception is made for unsigned char, which cannot have holes;
as some of the material in the draft regarding character types is
obviously wrong, I won't comment on whether this extends to other
character types.
The draft gives all this material as part of the RR rather than the
TC, as if it was justified by existing wording in the standard.
In my opinion, this is obviously wrong and a TC is required. As I
understand there are some machines where holes are required in a
practical implementation, I hope the final TC2 includes changes to
allow for them.
--
Mark Brader "Could you please continue the petty bickering?
msb@sq.com I find it most intriguing."
SoftQuad Inc., Toronto -- Data ("Haven", ST:TNG, Tracy Torme)
My text in this article is in the public domain.